Is CVE-2012-2665 fixed in LO?

Is CVE-2012-2665 fixed in LO?

On Thu, 2012-06-07 at 18:23 +0200, Petr Mladek wrote:
> Hi Caolan,
>
> I am a bit confused by all the security problems. Is CVE-2012-2665 fixed
> in LO-3.5?

Not yet. I wanted to wait to propose any more backports until the
backlog was cleared to try and avoid confusion :-)

So, I'm now requesting the following three additional commits to be
cherry-picked to 3-5

78f614e5fff70d4874322255cca739f430865f0a key-size
acc613a3236c61c8272bde1eadca5d8bf25f98f1 tag-hierarchy
4a7164429b727bd8fd6f183950e85e6225869364 count-and-order

to address CVE-2012-2665

I'd like to consider those three + the already cherry-picked
4036ee4db7b43cac9f892c2b9a2c545f0f838747 as our canonical solution to
CVE-2012-2665 (78f614e5fff70d4874322255cca739f430865f0a is technically
not really relevant but I reckon its easiest to bundle it into any
backports while we're at it to keep things simple)

C.

From 4036ee4db7b43cac9f892c2b9a2c545f0f838747 Mon Sep 17 00:00:00 2001
From: Caolán McNamara <caolanm@redhat.com>
Date: Wed, 30 May 2012 14:10:25 +0000
Subject: merge three base64 encoders/decoders together

Conflicts:

        filter/source/placeware/Base64Codec.cxx
        package/source/manifest/Base64Codec.cxx

Change-Id: Ic123c081fcf6ddcf5d61c5d5a3eab01db470014c
Signed-off-by: Miklos Vajna <vmiklos@suse.cz>
From 78f614e5fff70d4874322255cca739f430865f0a Mon Sep 17 00:00:00 2001
From: Caolán McNamara <caolanm@redhat.com>
Date: Mon, 28 May 2012 09:33:40 +0000
Subject: check key size

Change-Id: Ia909b0abb3ef84a9f0a14d42379f693ae9e70812

From acc613a3236c61c8272bde1eadca5d8bf25f98f1 Mon Sep 17 00:00:00 2001
From: Caolán McNamara <caolanm@redhat.com>
Date: Mon, 28 May 2012 09:35:31 +0000
Subject: unwind manifest xml parser and follow tag hierarchy model

so we validate that each tag is inside the right parent

Change-Id: Ibc82aeaf6b409ef2fed7de0cd8f15c164da65e53

From 4a7164429b727bd8fd6f183950e85e6225869364 Mon Sep 17 00:00:00 2001
From: Caolán McNamara <caolanm@redhat.com>
Date: Mon, 28 May 2012 10:43:09 +0000
Subject: count and order of receipt of properties doesn't matter

so stick imported properties into assigned slots and throw out empty ones when
finished. Reuse existing ids for this between import and export. Shuffle
FULLPATH to 0 as per import comment

Change-Id: I516116c5327498ad043f6e2fb9bd257599ade2a2

Gbp-Pq: Name CVE-2012-2665.diff